ROS2 视频流传输与 WebRTC 集成
机器人平台上的摄像头画面如何低延迟地送到浏览器或远程控制端，是监控与遥操作场景的常见需求。本文回答三个递进的问题：ROS2 怎么传输视频流；ROS2 是否用到了 WebRTC；WebRTC 又是如何接入 ROS2 通信体系的。关键结论均附事实来源，适合正在为机器人选型视频链路的 ROS2 开发者阅读。
一、ROS2 原生视频传输：基于 DDS
ROS2 的传输层是 DDS（Data Distribution Service），通过 rmw（ROS Middleware Interface）抽象隔离。各发行版默认实现是 Fast DDS（rmw_fastrtps_cpp），可以切换为 Cyclone DDS、RTI Connext，或非 DDS 的 Zenoh（ROS 2 官方中间件文档）。
在这套机制里，视频与普通消息没有本质区别，常用载体有三种：
| 消息类型 | 说明 |
|---|---|
sensor_msgs/Image | 原始未压缩像素 |
sensor_msgs/CompressedImage | JPEG/PNG 压缩 |
image_transport 插件 | 如 theora_image_transport、ffmpeg_image_transport（H.264） |
数据通路为：Publisher 将 Image 序列化为 CDR，DDS 按传输类型（共享内存 SHM / UDP / TCP）分片下发，Subscriber 反序列化还原（Vulcanexus 图像压缩教程、ffmpeg_image_transport）。
裸视频直接走 DDS 的代价
以 1080p RGB 为例，单帧约 6 MB（1920×1080×3 = 6,220,800 字节），30 fps 裸流约 1.5 Gbps（1920×1080×3×30×8 ≈ 1.49 Gbps）。未经压缩的原始视频直接交给 DDS 会带来三个问题：
- 序列化与拷贝开销大，CPU 占用高；
- 触发 DDS 大消息分片，UDP 多播环境下容易拥塞；
- 链路带宽占用高，挤占其他话题。
因此工程实践通常先编码压缩（H.264/VP8）再发布，或把视频流从 DDS 中移出，改走专用流媒体通道（Clearpath 的视频流优化实践）。
QoS 方面，视频话题常用 BEST_EFFORT 配合适当的 Depth；但关键链路有时仍需要 RELIABLE。两种选择并不存在对所有场景都最优的方案，需按场景权衡。
二、ROS2 并不原生支持 WebRTC
rmw/DDS 与 WebRTC 是两套独立的协议栈，解决的问题不同：
| 维度 | ROS2（DDS） | WebRTC |
|---|---|---|
| 定位 | 局域网内节点间发布/订阅 | 跨互联网实时音视频 |
| NAT 穿透 | 无（或需额外配置） | 自带 ICE/STUN/TURN |
| 加密 | 可选（TLS） | 强制 DTLS-SRTP |
| 拓扑 | 多播/共享总线 | P2P 或 SFU 转发 |
WebRTC 出现在 ROS2 生态中，基本都是为弥补 DDS 不擅长的场景：把机器人摄像头画面以低延迟推送到 Web 端，支撑远程监控与遥操作。
三、WebRTC 的接入方式：桥接节点
两套协议栈通过一个桥接节点衔接：
桥接节点同时承担两种身份：
- 普通 ROS2 节点：用
rclcpp订阅/image_raw，经cv_bridge转为cv::Mat，送入编码器。 - WebRTC peer：运行一份 WebRTC 栈（libwebrtc、aiortc、GStreamer
webrtcbin或 Pion 均可），把编码帧封装为VideoTrack，经 ICE/DTLS/SRTP 发出；反向通过DataChannel接收遥控指令，再以 ROS2 消息（如geometry_msgs/Twist）发布。
信令如何传递
「WebRTC 是否经过 ROS2 通信接口」的关键在信令阶段（SDP offer/answer 与 ICE candidate 交换），有两种做法：
| 方式 | 做法 | 适用 |
|---|---|---|
| 信令走 ROS2 | SDP/ICE 用 std_msgs/String 话题或 service，在机器人侧与（经 rosbridge 接入的）浏览器侧之间转发 | 复用 ROS2 网络，演示场景 |
| 信令走 WebSocket/HTTP | 桥接节点额外提供 WebSocket/HTTP 信令服务，浏览器直连 | 已知主流实现采用的方式 |
需要注意边界：WebRTC 协商完成后，真正的音视频与数据流走 P2P 或 SFU 直传，不再经过 DDS。严格地说，「WebRTC 通过 ROS2 通信接口通信」只发生在信令阶段（PHNTM Bridge 文档、Foxglove Remote Access）。
四、主流实现
| 项目 | 语言 | 特点 |
|---|---|---|
| PHNTM Bridge | C++ | 高性能 WebRTC ROS2 桥，ROS Image/CompressedImage 话题以 H.264 视频流推送到浏览器 |
| opentera-webrtc-ros | C++/Python | 基于 Google WebRTC 库的音视频/数据流节点，含遥操作功能，维护有 ros2 分支 |
| Foxglove | 平台服务 | 内建远程访问：image 数据转码为随带宽自适应的 WebRTC video track |
这些实现的信令均由各自的服务体系完成，不走 DDS。
要点
- ROS2 原生传视频走 DDS +
rmw，消息类型为Image/CompressedImage；裸视频开销大，发布前需要压缩。 - ROS2 不原生提供 WebRTC 能力，所有 WebRTC 功能来自社区桥接包。
- WebRTC 通过桥接节点接入：桥接节点既是 ROS2 的 subscriber/publisher，又是 WebRTC peer。
- 严格意义上「WebRTC 经过 ROS2 通信接口」只发生在信令阶段；媒体流协商完成后直传，不经 DDS。
- 涉及「主流」「一定」的判断需要项目实证支撑，不宜凭经验断言。